This change is not necessary for `NativeInterpreter` at all, but is
particularly useful for JET. For error reporting, which is the purpose
of `JETAnalyzer`, it is desirable to present error causes in a
user-understandable form even when concrete evaluation presents errors.
This requires analysis using regular abstract interpretation (constant
propagation) in general. However, to reduce false positives, the
precision that concrete evaluation brings is very important, and
completely disabling concrete evaluation is not desirable either.
Currently, `JETAnalyzer` aims to avoid this tradeoff by limiting
concrete evaluation to only some functions, but this approach does not
scale and occasionally causes problems like #59884.

This commit enables ad-hoc cancellation of concrete evaluation based on
the result of `concrete_eval_call`, allowing `JETAnalyzer` to fallback
to abstract interpretation only when concrete evaluation causes errors,
fundamentally avoiding such problems.

(cherry picked from commit c6091de)

This change is not necessary for `NativeInterpreter` at all, but is
particularly useful for JET. For error reporting, which is the purpose
of `JETAnalyzer`, it is desirable to present error causes in a
user-understandable form even when concrete evaluation presents errors.
This requires analysis using regular abstract interpretation (constant
propagation) in general. However, to reduce false positives, the
precision that concrete evaluation brings is very important, and
completely disabling concrete evaluation is not desirable either.
Currently, `JETAnalyzer` aims to avoid this tradeoff by limiting
concrete evaluation to only some functions, but this approach does not
scale and occasionally causes problems like #59884.

This commit enables ad-hoc cancellation of concrete evaluation based on
the result of `concrete_eval_call`, allowing `JETAnalyzer` to fallback
to abstract interpretation only when concrete evaluation causes errors,
fundamentally avoiding such problems.

(cherry picked from commit c6091de)

This change is not necessary for `NativeInterpreter` at all, but is
particularly useful for JET. For error reporting, which is the purpose
of `JETAnalyzer`, it is desirable to present error causes in a
user-understandable form even when concrete evaluation presents errors.
This requires analysis using regular abstract interpretation (constant
propagation) in general. However, to reduce false positives, the
precision that concrete evaluation brings is very important, and
completely disabling concrete evaluation is not desirable either.
Currently, `JETAnalyzer` aims to avoid this tradeoff by limiting
concrete evaluation to only some functions, but this approach does not
scale and occasionally causes problems like #59884.

This commit enables ad-hoc cancellation of concrete evaluation based on
the result of `concrete_eval_call`, allowing `JETAnalyzer` to fallback
to abstract interpretation only when concrete evaluation causes errors,
fundamentally avoiding such problems.

(cherry picked from commit c6091de)